FIG. 1a shows a communication system SYS for illustrating the background and the problems to be solved by the invention. In FIG. 1a a home network (Customer Premises Network) CPN comprises a number of terminal devices T1, T2, . . . Tn . . . TN. The home network CPN may be connected to a service network which is denoted with IMS-N in FIG. 1a. In the home network CPN or the connected service network IMS-N there is arranged a service providing server IMS-S which provides specific services to the terminal devices T1, T2, Tn . . . TN, e.g. in an IMS type communication system VoIP, video conferencing and IPTV.
The access procedure and delivery procedure is provided by a gateway apparatus which is denoted with HiGA in FIG. 1a. In response to an access message AC from a terminal device, e.g. T1, to the gateway apparatus HiGA, the service providing server IMS-S will deliver the requested service by means of a delivery message DL forwarded by the gateway apparatus HiGA. Normally, if the service providing server IMS-S and the terminal devices T1, T2, Tn . . . TN are of the same “type”, then there will be no problems in the accessing and provision (delivery) of the services of the service providing server IMS-S, even if the services also have application-specific attributes associated with them. However, if the service providing server IMS-S is of a first type and the terminal device is of a second type incapable to understand the specific first type control data (application-specific attributes) associated with the services, then only the services provided by the service providing server IMS-S can be delivered to the second type terminal device but there is no possibility that first type control data associated with the service is decoded and used in the second type terminal device. Hereinafter, to further illustrate this aspect, a more specific example relating to IMS services will be explained also to FIG. 1b, 1c. 
The examples in FIG. 1c, 1 b, 1c are for a case in which the gateway apparatus is formed by a HiGA (Home IMS GAteway) and the terminal device T1 (first type terminal device) is a SIP device (SIP: Session Initiation Protocol), and the terminal device T2 (second type terminal device) is a non-SIP device. As explained before, the HiGA is a functional block (gateway) residing in the home network CPN which thus enables SIP and non-SIP terminal devices to access IMS-based services provided from by the service providing server IMS-S. IMS-based services may include communication services such as VoIP (Voice over IP) and video conferencing, as well as other multimedia services, such as IPTV, as also indicated in FIG. 1a. 
One of the characteristics of for example IPTV offered as an IMS service is that it allows a personalisation of TV content delivered to end users, for example the delivery of personalized advertisements based on user identity and preference. For this purpose, the HiGA maintains a user profile in a user profile memory UP-MEM shown in FIG. 1b. Such a user profile may for example be stored in the exchange portion EX of the gateway device HiGA shown in FIG. 1c. A user profile is maintained for every subscription which is linked to an IMS service identity. For example, as shown in FIG. 1b, each user identity (USER-ID) is associated with a specific preference (control information) and service identification IMS-ID. For example, different TV programs may be available to each individual user in their EPG (Electronic Program Guide) such as, as shown in FIG. 1b, ID1=“dad”/control info=“sports”, ID2=“son”/control info=“movies and kids programs” and IDn=“mother”/control info=“advertisements”. IF such specific preferences (control info) are indicated, the HiGA will make sure that the requested service is delivered to the user (terminal device) in a personalised way by means of the control information.
For example, if a first type terminal device T1 sends a service delivery request including a user-ID=ID2, then HiGA will know that a personalized electronic program guide EPG2 is to be retrieved from the service providing server IMS-S and HiGA will send a request for EPG2 to the server IMS-S. Alternatively, if the server IMS-S includes a user-specific preference mapping table mapping between user identity ID and control information IMS-CTRL, as shown in FIG. 1c, it may be sufficient if the first type terminal device T1 merely sends its user-ID ID1 (first tape control information) to the server IMS-S through the HiGA and the server IMS-S will return the first type control information (control data) to the first type terminal device T1 which is capable of decoding and using the provided first type (personalized, i.e. user and service-specific) control information EPG1 In this way, personalised content can be delivered to a specific subscription and hence to a specific user, provided that the terminal device and the server run the same (first type) control protocol. Typically, in a communication system having an IMS server IMS-S, both the terminal device T1 and the server IMS-S run the same SIP control protocol and can therefore “talk” to each other using this protocol.
Whilst HiGA provides essentially an IMS-SIP proxy (exchange) functionality for providing IMS communication services to both SIP and non-SIP (e.g. UPnP (Universal Plug and Play)) home devices, the IMS system, i.e. the application server IMS-S in the home network CPN or in the interconnected services network IMS-N, provides a multitude of multimedia services, as shown in FIG. 1a, including IPTV, VoIP, video conferencing etc. and typically such IMS services could have application (service)-specific attributes (control information) which cannot be used and understood by standard terminal device T2 running a different second control protocol, as indicated in FIG. 1a. For example, the IPTV service might have application-specific attributes such as EPG (Electronic Program Guide) and service triggers. A voice over IP service may have specific attributes in terms of specific adverts or music. If the end terminal device is also an IMS-based terminal device, then of course there is no problem to deliver the application (service)-specific attributes associated with this service to a (first type SIP) terminal device T1. However, there is a problem if the terminal device is of a different type (second type), i.e. non-IMS-based, because in this case the application-specific attributes (control information) associated with this IMS-based service cannot be “understood” by the control protocol of a non-IMS-based first type terminal device T2. This problem does not only relate to the more sophisticated provision of personalized content from the server IMS-S but even to a simple request scenario.
For example, the first terminal device T1 may be capable of decoding a delivered MPEG2 stream by means of a service processor SP (MPEG2 decoder). However, it may use a HTTP (first type) control protocol for requesting this MPEG2 service from the server IMS-S. If the server IMS-S runs a second control protocol, for example SIP, then the first terminal device T1, not supporting IMS SIP, can not access media at the server IMS-S with the HTTP request. Another example is if the first terminal device T1 requests a service, e.g. a video streaming, requiring a certain bandwidth (certain resources) in the access network and the access network is incapable to provide the required resources. Since the first and second control protocols are different, the terminal device will not be capable e.g. to negotiate with the server IMS-S that a certain lower bandwidth is acceptable for a video streaming with e.g. lower quality.
Many off-the-shelf terminal devices T2, such as for example a simple standard Set-Top-Box STB, running simple request messages without having assigned to them specific user-IDs, are only capable to decode or run the service, but they are not capable to provide any user-specific features, i.e. they are “blind” and simply run the service in a user-unrelated fashion.